這段時間因為投入 iThome 鐵人賽文章的撰寫，平台的更新暫時停了下來。

為了避免思路斷掉，我決定在網站上增加一個「開發日誌」頁面，專門記錄平台的開發過程與背後的發想。這不只是功能展示，而是幫助我整理思路、累積脈絡，也希望能多一些使用者回饋與建議管道。

恰好不久前，我排隊排到都快忘記的 Kiro 試用申請 終於下來了。
收到通知時我還愣了一下，才想起原來我有申請過。既然機會來了，那就順勢把「開發日誌」交給 Kiro 試試吧。

初次體驗：Spec 模式的完整規劃

Kiro 的亮點主要集中在 Spec 與 Hook 兩大功能，這次主要著重在 Spec 模式的嘗試。
它的預設模型是 Claude 4 Sonnet，想必體驗不會太差，值得一試。

我一開始先嘗試了 Spec 模式，這個模式會把我輸入的一句簡單需求，轉化成詳細的：

• 開發需求說明
• 設計規劃文件
• 實作計畫與任務拆解

在過程中，Kiro 會不斷詢問我：

這樣的規劃是否符合需求？
是否需要調整？

等文件確定後，它還會幫我生成清楚的 Task 清單，只要依照步驟去完成，就能逐步做出功能。

聽起來很理想，幾乎像一位嚴謹的專案經理，幫你把腦海中的想法化為完整的開發藍圖。

實際卡關：規劃太完整，效率卻下降

我原本對「開發日誌」的需求非常簡單：

• 我能夠發表文章
• 使用者能看到並留言

基本上就是一個最小可行版本（MVP）的部落格功能。

但 Spec 模式 卻幫我生成了超完整的規劃，甚至拆出了將近 20 個 Tasks，有些平時 Vibe 可以快速完成的任務，硬是拆成了超多步驟。

看起來很完美，但實際執行起來：

• 每個步驟都需要很久 → 從提出需求到開始實作第三個步驟就已經花了半小時。
• 看不到成果 → 前面都是基礎設計，沒辦法先看到任何介面或功能。
• 過於冗長 → 規劃的內容詳細到我懶得逐字看，大部分只是快速掃過就按下同意。

最後，做到第三個 Task 我終於受不了了，有點擔心花了一兩個小時的時間和使用次數，結果還不滿意或甚至不能用，於是決定 中斷 Spec 模式，改用 Vibe 模式。

換個角度：Vibe 模式的嘗試

切換到 Vibe 模式 之後，體驗就完全不同了。

這個模式比較像 Cursor 或其他 AI 開發工具的感覺：
能快速接收需求 → 生成程式碼 → 立即在專案中驗證。

我再次輸入需求：

使用與當前平台類似的綠色風格，實現開發日誌頁面:
1. 開發者可以發布文章
2. 其他使用者登入可以留言或按讚
3. 以時間軸方式排序文章列表

它很快就幫我生成了基礎架構，並且能馬上看到成果。
雖然不像 Spec 模式那樣面面俱到，但勝在 快，而且能立即驗證效果並持續調整。

最後，我透過 Vibe 模式完成了開發日誌，順利把這個區塊放上網站。
雖然功能還很簡單，但已經能用來紀錄開發心得，達到我的簡單目標。

我的結論：Spec 要慎選時機，Vibe 更適合快速開發

這次實測 Kiro，我的簡單心得：

• Spec 模式 適合 大型、複雜、需要完整規劃的功能
  → 像是設計複雜的新模組、建立大型系統框架。
• Vibe 模式 適合 快速開發、小功能原型、快速迭代
  → 更符合日常需求，能讓我即時看到成果。

前者穩健，後者靈活。未來我會試試依需求選擇，而不是盲目一開始就用 Spec。或許，也可以試試用 Spec 生成詳細需求清單，再用 Vibe 模式快速實作。

寫下開發日誌的意義

雖然這次主要是測試 Kiro，但也真正把「開發日誌」功能做出來，結果還算不錯。

參加鐵人賽的過程中，時間用來寫文章導致忽略平台進度，
而有了開發日誌後，即便沒有更新平台功能，也可以稍微花點時間對平台的優化方向或平時的一些發想做一些紀錄，對自己是一種督促。

鐵人賽結束後，我計劃回到平台開發，繼續把更多想法實作出來。
而 開發日誌，會是陪伴我一路走下去的重要工具。